Security, Compliance & Quality
1. Security Requirements
Your anomaly detection service must implement the following security measures:
1.1 HTTPS Protocol
The anomaly detection service is external to Candescent data centers. All communication must use HTTPS with TLS 1.2 or higher with server certificate authentication.
1.2 Client Certificate Authentication (Optional)
In addition to server certificate authentication, you may implement client certificate authentication where Candescent must present a signed certificate verifying their identity during the HTTPS handshake.
1.3 HTTP Basic Authentication
You must validate the HTTP Basic Authentication header passed by Candescent.
Implementation Requirements:
- Issue a pair of client credentials (Client ID and Client Secret) to Candescent
- Credentials must be kept secure
- Validate the Authorization header on every request
Authorization Header Format:
Authorization: Basic Base64(client_id:client_secret)
Example:
Authorization: Basic OHFvcDFjNmwxdjlzNnRmMm5iaDA6cmU0aTA5aHZkcTY5bjAwZG45Mzg=
1.4 IP Whitelisting
Your service should whitelist Candescent IP addresses. The specific IP addresses will be provided during the integration process.
1.5 Security Configuration Options
You may implement one or more of the following security mechanisms:
- Client Certificate Authentication
- HTTP Basic Authentication
- Both Client Certificate AND HTTP Basic Authentication
2. Nonfunctional Requirements
2.1 Performance Expectations
Your anomaly detection service must meet the following performance requirements:
| API | Ideal Response Time | Maximum Response Time |
|---|---|---|
| getRiskProfile | < 200 milliseconds | 2 seconds |
| deleteUserBankingActivities | < 200 milliseconds | 2 seconds |
| createBankingActivities (bulk) | < 2 seconds | 5 seconds |
Circuit Breaker Behavior:
If response times consistently exceed the maximum thresholds, Candescent will:
- Open the circuit (using circuit breaker pattern)
- Respond to UI clients with a challenge response to the user
- Keep the circuit open until your API performance recovers
2.2 High Availability
As an external service, you are responsible for ensuring:
- High availability
- Performance consistency
- System reliability
- Disaster recovery capabilities
2.3 Prerequisites for Production
Historical Data Loading:
Historical user event data must be loaded for each Financial Institution prior to enabling Anomaly Detection for that institution in production.
- Recommended duration: 90 days of historical event data
- Data delivery: Via the bulk API (createBankingActivities) in a streaming manner
- Source: Candescent's data platform system
3. Status Codes and Messages
Your implementation must return appropriate status codes. The following status codes are defined:
| Status Code | Type | Message |
|---|---|---|
SUCCESS | Success | (Operation completed successfully) |
SUCCESS_RISK_PROFILE_NOT_EVALUATED | Success | (Request accepted but risk not evaluated) |
ERROR_INTERNAL_SERVER | Error | Operation failed due to some internal server error |
ERROR_NOT_SUPPORTED | Error | Real-time risk score not supported by product license |
ERROR_INVALID_CLIENT_ID | Error | Invalid client id |
ERROR_INVALID_MSG | Error | The message passed to the API is invalid |
ERROR_RISK_PROFILE_CHECK_NOT_CONFIGURED | Error | Risk profile check is not configured |
ERROR_INVALID_TRANSACTION_ID | Error | Invalid or no transaction id header passed |
ERROR_TIMEOUT | Error | Request was received successfully but there was an internal server timeout. Risk engine was not able to return a risk score |
ERROR_MAINTENANCE | Error | System unavailable due to maintenance |
ERROR_INVALID_USER_ID | Error | Invalid User Id |
ERROR_INVALID_LOGIN_NAME | Error | Invalid Login Name |
This document is confidential and proprietary. The information contained herein may not be copied, reproduced, transmitted, or used without the express written consent of Candescent Corporation.